Network Working Group K. Varadhan 
Request for Comments: 1403 OARnet 
Obsoletes: 1364 January 1993 


BGP OSPF Interaction 
Status of this Memo 


This RFC specifies an IAB standards track protocol for the Internet 
community, and requests discussion and suggestions for improvements. 
Please refer to the current edition of the "IAB Official Protocol 
Standards" for the standardization state and status of this protocol. 
Distribution of this memo is unlimited. 


Abstract 
This memo defines the various criteria to be used when designing an 
Autonomous System Border Routers (ASBR) that will run BGP with other 
ASBRs external to the AS and OSPF as its IGP. This is a 


republication of RFC 1364 to correct some editorial problems. 
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Les 


Introduction 


This document defines the various criteria to be used when designing 
an Autonomous System Border Routers (ASBR) that will run BGP 
[RFC1267] with other ASBRs external to the AS, and OSPF [RFC1247] as 
its IGP. 


This document defines how the following fields in OSPF and attributes 
in BGP are to be set when interfacing between BGP and OSPF at an 
ASBR: 


OSPF cost and type vs. BGP INTER-AS METRIC 
OSPF tag vs. BGP ORIGIN and AS_PATH 
OSPF Forwarding Address vs. BGP NEXT_HOP 


For a more general treatise on routing and route exchange problems, 
please refer to [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist. 


This document uses the two terms "Autonomous System" and "Routing 
Domain". The definitions for the two are below: 


The term Autonomous System is the same as is used in the BGP-3 RFC 
[RFC1267], given below: 


"The use of the term Autonomous System here stresses the fact 
that, even when multiple IGPs and metrics are used, the 
administration of an AS appears to other ASs to have a single 
coherent interior routing plan and presents a consistent picture 
of what networks are reachable through it. From the standpoint 
of exterior routing, an AS can be viewed as monolithic: 
reachability to networks directly connected to the AS must be 
equivalent from all border gateways of the AS." 


The term Routing Domain was first used in [ROUTE-LEAKING] and is 
given below: 


"A Routing Domain is a collection of routers which coordinate 
their routing knowledge using a single (instance of) a routing 
protocol." 


This document follows the conventions embodied in the Host 
Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST", 
"SHOULD", and "MAY" for the various requirements. 
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2. Route Exchange 


This section discusses the constraints that must be met to exchange 
routes between an external BGP session with a peer from another AS 
and internal OSPF routes. 


BGP does not carry subnet information in routing updates. Therefore, 
when referring to a subnetted network in the OSPF routing domain, we 
consider the equivalent network route in the context of BGP. 
Multiple subnet routes for a subnetted network in OSPF are collapsed 
into one network route when exported into BGP. 


2.1. 


Varadhan 


Exporting OSPF routes into BGP 


The administrator MUST be able to selectively export OSPF 
routes into BGP via an appropriate filter mechanism. 


This filter mechanism MUST support such control with the 
granularity of a single network. 


Additionally, the administrator MUST be able to filter based 
on the OSPF tag and the various sub-fields of the OSPF tag. 
The settings of the tag and the sub-fields are defined in 
section 4 in more detail. 


fe) The default MUST be to export no routes from OSPF into 
BGP. A single configuration parameter MUST permit all 
OSPF inter-area and intra-area routes to be exported 
into BGP. 


OSPF external routes of type 1 and type 2 MUST never be 
exported into BGP unless they are explicitly configured. 


When configured to export a network, the ASBR MUST advertise 
a network route for a subnetted network, as long as at least 
one subnet in the subnetted network is reachable via OSPF. 


The network administrator MUST be able to statically 
configure the BGP attribute INTER-AS METRIC to be used for 
any network route. 


(0) By default, the INTER_AS METRIC MUST not be set. This 
is because the INTER_AS METRIC is an optional attribute 
in BGP. 


Explanatory text: The OSPF cost and the BGP INTER-AS METRIC 
are of different widths. The OSPF cost is a two level 
metric. The BGP INTER-AS METRIC is only an optional non- 
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transitive attribute. Hence, a more complex BGP INTER-AS 
METRIC-OSPF cost mapping scheme is not necessary. 


When an ASBR is advertising an OSPF route to network Y to 
external BGP neighbours and learns that the route has become 
unreachable, the ASBR MUST immediately propagate this 
information to the external BGP neighbours. 


An implementation of BGP and OSPF on an ASBR MUST have a 
mechanism to set up a minimum amount of time that must elapse 
between the learning of a new route via OSPF and subsequent 
advertisement of the route via BGP to the external 
neighbours. 


(0) The default value for this setting MUST be 0, indicating 
that the route is to be advertised to the neighbour BGP 
peers instantly. 


Note that [RFC1267] mandates a mechanism to dampen the 
inbound advertisements from adjacent neighbours. 


Importing BGP routes into OSPF 


BGP implementations SHOULD allow an AS to control 
announcements of BGP-learned routes into OSPF. 
Implementations SHOULD support such control with the 
granularity of a single network. Implementations SHOULD also 
support such control with the granularity of an autonomous 
system, where the autonomous system may be either the 
autonomous system that originated the route or the autonomous 
system that advertised the route to the local system 
(adjacent autonomous system). 


fe) The default MUST be to export no routes from BGP into 
OSPF. Administrators must configure every route they 
wish to import. 


A configuration parameter MAY allow an administrator to 
configure an ASBR to import all the BGP routes into the 


OSPF routing domain. 


The administrator MUST be able to configure the OSPF cost and 
the OSPF metric type of every route imported into OSPF. 


fe) The OSPF cost MUST default to 1; the OSPF metric type 
MUST default to type 2. 
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3% Routes learned via BGP from peers within the same AS MUST not 
be imported into OSPF. 


4. The ASBR MUST never generate a default route into the OSPF 
routing domain unless explicitly configured to do so. 


A possible criterion for generating default into an IGP is to 
allow the administrator to specify a set of (network route, 
AS_PATH, default route cost, default route type) tuples. If 
the ASBR learns of the network route for an element of the 
set, with the corresponding AS_PATH, then it generates a 
default route into the OSPF routing domain, with cost 
"default route cost" and type, "default route type". The 
lowest cost default route will then be injected into the OSPF 
routing domain. 


This is the recommended method for originating default routes 
in the OSPF routing domain. 


BGP Identifier and OSPF router ID 


The BGP identifier MUST be the same as the OSPF router id at all 
times that the router is up. 


This characteristic is required for two reasons. 
a Synchronisation between OSPF and BGP 


Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3, 
belong to the same autonomous system. 


Both RT1 and RT2 have routes to an external network X and 
import it into the OSPF routing domain. RT3 is advertising 
the route to network X to other external BGP speakers. RT3 
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must use the OSPF router ID to determine whether it is using 
RT1 or RT2 to forward packets to network X and hence build the 
correct AS_ PATH to advertise to other external speakers. 


More precisely, RT3 must determine which ASBR it is using to 
reach network X by matching the OSPF router ID for its route 
to network X with the BGP Identifier of one of the ASBRs, and 
use the corresponding route for further advertisement to 
external BGP peers. 


ii It will be convenient for the network administrator looking at 
an ASBR to correlate different BGP and OSPF routes based on 
the identifier. 


4. Setting OSPF tags, BGP ORIGIN and AS_PATH attributes 


The OSPF external route tag is a "32-bit field attached to each 


external route . . . It may be used to communicate information 
between AS boundary routers; the precise nature of such information 
is outside the scope of [the] specification." [RFC1247] 


OSPF imports information from various routing protocols at all its 
ASBRs. In some instances, it is possible to use protocols other than 
EGP or BGP across autonomous systems. It is important, in BGP, to 
differentiate between routes that are external to the OSPF routing 
domain but must be considered internal to the AS, as opposed to 
routes that are external to the AS. 


Routes that are internal to the AS and that may or may not be 
external to the OSPF routing domain will not come to the various BGP 
speakers from other BGP speakers within the same autonomous system 
via BGP. Therefore, ASBRs running BGP must have knowledge of this 
class of routes so that they can advertise these routes to the 
various external AS without waiting for BGP updates from other BGP 
speakers within the same autonomous system about these routes. 


Additionally, in the specific instance of an AS intermixing routers 
running EGP and BGP as exterior gateway routing protocols and using 
OSPF as an IGP, then within the autonomous system, it may not be 
necessary to run BGP with every ASBR running EGP and not running BGP, 
if this information can be carried in the OSPF tag field. 


We use the external route tag field in OSPF to intelligently set the 
ORIGIN and AS_PATH attributes in BGP. Both the ORIGIN and AS_PATH 
attributes are well-known, mandatory attributes in BGP. The exact 
mechanism for setting the tags is defined below. 


The tag is broken up into sub-fields shown below. The various sub- 
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fields specify the characteristics of the route imported into the 
OSPF routing domain. 


The high bit of the OSPF tag is known as the "Automatic" bit. When 
this bit is set to 1, the following sub-fields apply: 

0x0- 0: 00808 OO" 00. Te de De De Tin 222 22D 2 DS 3 3 
0-12.38 A Db TE 9 Od 232A E 7 8 Oe OF DL 2.3) Ae. 6 7B: 9 OA 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
lalc|p 1| ArbitraryTag | AutonomousSystem 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


a is 1 bit called the Automatic bit, indicating that the 
Completeness and PathLength bits have been generated 
automatically by a router. The meaning of this characteristic 
and its setting are defined below. 


G is 1 bit of Completeness information. The meaning of this 
characteristic and its settings are defined below. 


pl are 2 bits of PathLength information. The meaning of this 
characteristic and its setting are defined below. 


ArbitraryTag 
is 12 bits of tag information, which defaults to 0 but can be 
configured to anything else. 


AutonomousSystem (or *‘‘AS’’) 
is 16 bits, indicating the AS number corresponding to the 
route, 0 if the route is to be considered as part of the local 
AS. 


local_AS 
The term ‘local_AS’ refers to the AS number of the local 
OSPF routing domain. 


next_hop_AS 
‘next_hop_AS’ refers to the AS number of an external BGP 


peer. 
When the Automatic bit is set to 0, the following sub-fields apply: 
02-010: 0: 00 Or" 0 OO yn T A es ae As se DD DDD DD De D3 E) 
OQ. 23-4 SG. 78! OOD 2 B74 e-b 6 7 Be 9 OF 1 23: Ae 565 T <8: 9 Oe L 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Jal LocalInfo | 


+-4+-4-4-4-4-4-4-4-4-4-4-4-4-4+-4-4+-4-4+-4-4-4-4+-4-4-4+-4+-4+-4-4-4-4-4 
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a is 1 bit called the Automatic bit, set to 0. 


LocaliInfo 
is 31 bits of an arbitrary value, manually configured by the 
network administrator. 


The format of the tag for various values of the characteristics 
bits is defined below. 


4.1. Semantics of the characteristics bits 


The Completeness and PathLength characteristics bits define the 
characteristic of the route imported into OSPF from other ASBRs in 
the autonomous system. This setting is then used to set the 
ORIGIN and NEXT_HOP attributes when re-exporting these routes to 
an external BGP speaker. 


fe) The Automatic characteristic bit is set when the Completeness 
and PathLength characteristics bits are automatically set by 
a border router. 


For backward compatibility, the Automatic bit must default to 
0O and the network administrator must have a mechanism to 
enable automatic tag generation. Nothing must be inferred 
about the characteristics of the OSPF route from the tag 
bits, unless the tag has been automatically generated. 


(0) The Completeness characteristic bit is set when the source of 
the incoming route is known precisely, for instance, from an 
IGP within the local autonomous system or EGP at one of the 
autonomous system’s boundaries. It refers to the status of 
the path information carried by the routing protocol. 


fe) The PathLength characteristic sub-field is set depending on 
the length of the AS_PATH that the protocol could have 
carried when importing the route into the OSPF routing 
domain. The length bits will indicate whether the AS_PATH 
attribute for the length is zero, one, or greater than one. 


Routes imported from an IGP will usually have an AS_PATH of 
length of 0, routes imported from an EGP will have an AS_PATH 
of length 1, BGP and routing protocols that support complete 
path information, either as AS_PATHs or routing domain paths, 
will indicate a path greater than 1. 


The OSPF tag is not wide enough to carry path information 


about routes that have an associated PathLength greater than 
one. Path information about these routes will have to be 
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carried via BGP to other ASBRs within the same AS. Such 
routes must not be exported from OSPF into BGP. 


4.2. Configuration parameters for setting the OSPF tag 


(0) There MUST be a mechanism to enable automatic generation of 
the tag characteristic bits. 


o Configuration of an ASBR running OSPF MUST include the 
capability to associate a tag value, for the ArbitraryTag, or 
LocalInfo sub-field of the OSPF tag, with each instance of a 
routing protocol. 


fe) Configuration of an ASBR running OSPF MUST include the 
capability to associate an AS number with each instance of a 
routing protocol. 


Associating an AS number with an instance of an IGP is 
equivalent to flagging those set of routes imported from the 
IGP to be external routes outside the local autonomous 
system. 


Specifically, when the IGP is RIP [RFC1058, RFC1388], it 


SHOULD be possible to associate a tag and/or an AS number 
with every interface running RIP on the ASBR. 
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4.3. Manually configured tags 
02101003, (Qe -<O8 OF Oi 300 T say Lk dy Ah De es DE Ds 22a De Ds 2 Oe B33 
O01 2:3) 4-6: 7 8: 9: Ord. 2 3 4S 6 7 8 9s OO D2 3) ASG: 8: 9 Oe A. 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|o] LocalInfo | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


This tag setting corresponds to the administrator manually setting 
the tag bits. Nothing MUST be inferred about the characteristics 
of the route corresponding to this tag setting. 


For backward compatibility with existing implementations of OSPF 
currently deployed in the field, this MUST be the default setting 
for importing routes into the OSPF routing domain. There MUST be 
a mechanism to enable automatic tag generation for imported 
routes. 


The OSPF tag to BGP attribute mappings for these routes MUST be 


Automatic=0, LocalInfo=Arbitrary_Value => 


ORIGIN=<INCOMPLETE>, AS_PATH=<local_AS> 

4.4. Automatically generated tags 
4.4.1. Routes with incomplete path information, PathLength = 0. 
0x0 O50 O EE O ad sh ed, a, S222 DDD DD D2 2323 
45: 6p 78: QO. Oo ak, 2. Se AP Bs O BN Oe Oe T 22 23) A 25: 56s Pg 9s Oe 
=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
ArbitraryTag | AutonomousSystem 

=-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+—+ 
= 
+—+ 
O 
+—+ 
O 
+—+ 
jo) 
+—+ 


These are routes imported from routing protocols with 
incomplete path information and cannot or may not carry the 
neighbour AS or AS path as part of the routing information. 


The OSPF tag to BGP attribute mappings for these routes MUST be 


Automatic=1, Completeness=0, PathLength=00, AS=0 => 
ORIGIN=<EGP>, AS _PATH=<local_AS> 
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4.4.2 Routes with incomplete path information, PathLength = 1. 


0 001 LEDET a 2 2 22 2.23 
6 8 9 0 23.64 9G FE BEG? QD 3 5 6 8 9 0 
SRF R FR FFF ete e atta ee aae tata ta tat 
ArbitraryTag | AutonomousSystem 
=papapafppe p p ee a pa e pa e 


0 0 0 1 2 2 2 2 3 
45 7 1 1-2 4 7 1 


+—+ 
= 
+— + 
O 
+—+ 
oO 
+—+ 
= 
+—+ 


These are routes imported from routing protocols with 
incomplete path information. The neighbour AS is carried in 
the routing information. 


The OSPF tag to BGP attribute mappings for these routes MUST be 


Automatic=1, Completeness=0, PathLength=01, AS=<next_hop_AS> 
=> ORIGIN=<EGP>, AS_PATH=<local_AS, next_hop_AS> 


This setting SHOULD be used for importing EGP routes into the 
OSPF routing domain. This setting MAY also be used when 
importing BGP routes whose ORIGIN=<EGP> and 
AS_PATH=<next_hop_AS>; if the BGP learned route has no other 
transitive attributes, then its propagation via BGP to ASBRs 


internal to the AS MAY be suppressed. 
4.4.3. Routes with incomplete path information, PathLength >= 1. 
O20! 20050: %0 E SE pds Dee BPD ID. De De De 2D, By 2 2 393 
45.6 7 28> OQ) D2) 8°24, (BOF OY 8-90. A, 2-3). 6 TBS 9 Oe 
—+—4+-4-4+-4+-4-4-4-4-4-4+-4+-4+-4+-4+-4-4-4-4-4-4-4-4-4-4-4-4-4+ 
ArbitraryTag | AutonomousSystem 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+— + 
= 
+—+ 
jo) 
+—+ 
= 
+— + 
O 
+—+ 


These are routes imported from routing protocols with truncated 
path information. 


The OSPF tag to BGP attribute mappings for these routes MUST be 
Automatic=1, Completeness=0, PathLength=10, AS=don’t care 

These are imported by a border router, which is running BGP to 
a stub domain, and not running BGP to other ASBRs in the same 


AS. This causes a truncation of the AS_PATH. These routes 
MUST not be re-exported into BGP at another ASBR. 
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4.4.4. Routes with complete path information, PathLength = 0. 
O020™ Oi OO AP AS a Ae a TE D928 DD De De 2D 2D E 3 
ANS: 6 Tg 9 OL 2°34 4 56. SF B89 0 12 3B AS. 6 Bs 9 OL 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
ArbitraryTag | AutonomousSystem 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+—+ 
= 
+— + 
= 
+—+ 
O 
+—+ 
jo) 
+—+ 


These are routes imported from routing protocols with either 
complete path information or are known to be complete through 
means other than that carried by the routing protocol. 


The OSPF tag to BGP attribute mappings for these routes MUST be 


Automatic=1, Completeness=1, PathLength=00, AS=0 


=> ORIGIN=<EGP>, AS_PATH=<local_AS> 
This SHOULD be used for importing routes into OSPF from an IGP. 
4.4.5. Routes with complete path information, PathLength = 1. 
0-00 -07070 T-L 1 dy T Wh, A a L 2222 2222 22 22 3-3 
43) 6. T 859° OT, 2 3rd 568 8 910 23 Abb TBs OO: 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
ArbitraryTag | AutonomousSystem 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+—+ 
= 
+— + 
= 
+—+ 
S 
+—+ 
= 
+—+ 


These are routes imported from routing protocols with either 
complete path information, or are known to be complete through 
means other than that carried by the routing protocol. The 
routing protocol also has additional information about the 
neighbour AS of the route. 


The OSPF tag to BGP attribute mappings for these routes MUST be 


Automatic=1, Completeness=1, PathLength=01, AS=next_hop_AS 
=> ORIGIN=<IGP>, AS_PATH=<local_AS, next_hop_AS> 


This setting SHOULD be used when the administrator explicitly 
associates an AS number with an instance of an IGP. This 
setting MAY also be used when importing BGP routes whose 
ORIGIN=<IGP> and AS_PATH=<next_hop_AS>; if the BGP learned 
route has no other transitive attributes, then its propagation 
via BGP to other ASBRs internal to the AS MAY be suppressed. 
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4.4.6. Routes with complete path information, PathLength >= 1. 
OOO O00: 22 Ts A A A a 292 BD De 222 33 
405: 6. E o 9 OL, 2.34 BG. FF BO -O- 12 3 A 6 e 9 OL 
—+—4+-4-4+-4+-+4+-4+-4-4-4+-4+-4+-4+-4+-4+-4-4-4-4-4-4-4-4-4-4-4-4-4+ 
ArbitraryTag | AutonomousSystem 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+—+ 
= 
+— + 
= 
+— + 
= 
+—+ 
jo) 
+—+ 


These are routes imported from routing protocols with complete 
path information and carry the AS path information as part of 
the routing information. 


The OSPF tag MUST be set to 
Automatic=1, Completeness=1, PathLength=10, AS=don’t care 


These routes MUST not be exported into BGP because these routes 
are already imported from BGP into the OSPF RD. Hence, it is 
assumed that the BGP speaker will convey this information to 
other BGP speakers within the same AS via BGP. An ASBR 
learning of such a route MUST wait for the BGP update from its 
internal neighbours before advertising this route to external 
BGP peers. 


Note that an implementation MAY import BGP routes with a path 
length of 1 and no other transitive attributes directly into 
OSPF and not send these routes via BGP to ASBRs within the same 
AS. In this situation, it MUST use tag settings corresponding 
to 4.4.2, or 4.4.5. 


4.5. Miscellaneous tag settings 


02050: 0) 00." O20 OO Td ee TTD de D2 22 2 22 22233 
0- 1-23 40,6 7 8-9 0 12 34 567 89 OL 2 3: A 3 6. 7B 9 0 L 
$ototatatatatititotitoitititatatatatitototititititatatatatitototet 

}1|x]1|1I Reserved for future use 
$ototatatatatitototititotitatatatatitototititotitatatatatitototot 


The value of PathLength=11 is reserved during automatic tag 
generation. Routers MUST not generate such a tag when importing 
routes into the OSPF routing domain. ASBRs MUST ignore tags which 
indicate a PathLength=11. 
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4.6. Summary of the tag sub-field setting 


The following table summarises the various combinations of 
automatic tag settings for the Completeness and PathLength sub- 
field of the OSPF tag and the default behaviour permitted for each 


setting. 
Completeness := 0 | 1 
PathLength := 00 | 01 | 10 | 11 
ORIGIN := <INCOMPLETE> | <IGP> | <EGP> 
AS_PATH := valid AS path settings as defined in BGP 
PathLength ==> 00 01 10 11 
Completeness 
| | $o-- 5-555-555-5555 5555-5 
vv 
= NO <EGP> <EGP> never export reserved 


5x 


<local_AS> <local_AS,next_hop_AS> 


YES | <IGP> <IGP> out of band reserved 
| <local_AS> <local_AS,next_hop_AS> 


The "out of band" in the table above implies that OSPF will not be 
able to carry everything that BGP needs in its routing 
information. Therefore, some other means must be found to carry 
this information. In BGP, this is done by running BGP to other 
ASBRs within the same AS. 


Setting OSPF Forwarding Address and BGP NEXT_HOP attribute 


Forwarding addresses are used to avoid extra hops between multiple 
routers that share a common network and that speak different routing 
protocols with each other. 


Both BGP and OSPF have equivalents of forwarding addresses. In BGP, 
the NEXT_HOP attribute is a well-known, mandatory attribute. OSPF 
has a Forwarding address field. We will discuss how these are to be 
filled in various situations. 
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Consider the 4 router situation below: 


RT1 and RT2 are in one autonomous system, RT3 and RT4 are in another. 
RT1 and RT3 are talking BGP with each other. 
RT3 and RT4 are talking OSPF with each other. 


4+----- + 4+----- + 
| RT1 | | RT2 | 
4+----- + 4+----- + 
| | common network 
---+ a H ee ee ey ee ey ee ee + See toe Se ay rag pee ad me Sy See at ek em Sg ee 
<BGP> | 
4+----- + <OSPF> 4+----- + 
| RT3 | | RT4 | 
4+----- + 4+----- + 


- Importing network X to OSPF: 


Consider an external network X, learnt via BGP from RT1. 


RT3 MUST always fill the OSPF Forwarding Address with the BGP 
NEXT_HOP attribute for the route to network X. 


- Exporting network Y to BGP: 


Consider a network Y, internal to the OSPF routing domain, 
RT3’s route to network Y is via RT4, and network Y is to be 
exported via BGP to RT1l. 


If network Y is not a subnetted network, RT3 MUST fill the 
NEXT_HOP attribute for network Y with the address of RT4. 
This is to avoid requiring packets to take an extra hop 
through RT3 when traversing the AS boundary. This is similar 
to the concept of indirect neighbour support in EGP [RFC888, 
RFC827]. 


6. Security Considerations 


Security issues are not discussed in this memo. 
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